COMMENT ⊗   VALID 00008 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002				Using REVED		2 October 1976
C00004 00003			Unit reverberators
C00008 00004			Complex reverberators
C00012 00005			The pointer
C00015 00006			Impulse responses
C00017 00007			Files
C00019 00008			Further information
C00020 ENDMK
C⊗;
			Using REVED		2 October 1976
Most interactions with REVED will center around two major structures.
These are discussed below, along with a few other necessary or useful
capabilities of REVED.  No attempt is made, however, to give a complete
tutorial on reverberator design; only the rudiments of using this
particular design program are laid out.
	End products of REVED are complex reverberator designs which
are intended to simulate the overall acoustics of a room.  Input to
the complete reverberator is monophonic, and output is any number of
channels (although the music compiler handles a maximum of four).
Complex reverberators are built up by connecting simple unit reverberators
together.  Therefore, the first conceptual structure that must be
understood is the unit reverberator.
		Unit reverberators
	Currently, REVED supports only one kind of unit reverberator,
the first-order all-pass.  Several different interdependent parameters
are useful in describing and understanding these units.  By giving
appropriate commands it is possible to change any of the parameters
displayed for a special "scratch" unit.  Typically, this scratch unit
would be altered until it was satisfactory, and then a copy of it
would be linked into the complete reverberator where desired.  All
commands altering unit parameters apply to this special scratch unit,
never to units already linked in.  In the event that a unit previously
linked in needs to be altered, it may be copied into the scratch unit,
changed, and replaced.  To change the value of a parameter, simply type
the name of the parameter (first letters are sufficient) followed by
the new value.
	Because the parameters are interdependent, a change in one
of them will affect others.  Sometimes it may be desirable to specify
that a certain parameter will be held fixed when another is changed.
One of three parameters may be so specified by giving its name (again,
first letters suffice) after the new value in a parameter changing command.  
In general, allowable choices are GAIN, DELAY, and TIME; but specific
commands may not permit all of these as possiblilites (because of the
interdependencies).
	An additional feature is that the current GAIN or DELAY may be
changed by multiplying or dividing it by some factor, rather than by
stating the new value explicitly.  To do this, type "*" (or "/")
followed immediately by the factor instead of typing the new value in
these commands.  If the factor itself is omitted, the last factor typed
for that command will be used.  A slight variation of this format
applies to the #Samples command: substituting "+" (or "-") followed by
an integer in place of the new value causes the resulting value to be
that many prime numbers greater (or less) than the current value.  Here,
too, the last increment typed is used as the default if the integer is
omitted.  These features are intended to facilitate the construction
of complex reverberators, discussed below.
		Complex reverberators
	As was mentioned before, complex reverberators are made by
connecting many unit reverberators together.  Only a restricted form
of connection is allowed in REVED, namely, a unit can get its input
from only one source -- either the input signal, or the output of
an intervening unit.  Units are permitted to give their outputs to
any number of succeeding units.  When this multiplicity of outputs
occurs, it will be referred to as branching (since a diagram of the
connections bears some resemblance to a tree with its root at the
input signal).  The "leaves" of this tree will be the outputs  of
the whole reverberator, and a typical finished tree will exhibit a
pleasing symmetry in its branching.  Unfortunately, limitations in
display capabilities make it impractical to actually draw such a
tree on the display screen.  Instead, a familiar indentation notation
-- like that used for outlines in books and papers -- is used to
indicate the connections among the units.  One slight refinement is
added for convenience, though: so long as there is no branching in
the units listed so far, the list of units will not be indented.
A simple example should serve to illustrate the relationship between
the tree structure and the indented listing.
	Consider:

[Input Signal]
[Unit 1]
[Unit 2]
   [Unit 3]
      [Unit 4]
      [Unit 5]
   [Unit 6]
      [Unit 7]
      [Unit 8]

In the actual display, of course, the units will be described by a
few parameters, not by name, but here the names are helpful.  In this
case, Unit 1 gets input from the Input Signal, and gives its output to
Unit 2, which (as required) gets input from no other source.  Next,
Unit 2 gives its output to both Unit 3 and Unit 6.  Continuing in like
manner, Unit 3 gives its output to Unit 4 and Unit 5, both of which
are "leaves" of the tree, and so give their output to appropriate output
channels for the whole reverberator.  Similarly, Unit 6 gives its output
to Unit 7 and Unit 8, which are also connected to output channels.
		The pointer
	For purposes of editing the tree, the screen display will
include one other item, a pointer into the tree.  Any commands
involving the tree (except when treated as a whole) will depend on
the location of this pointer.  Three commands are provided for moving
around in the tree; all of them are single character commands and
do not require a carriage return after them (unless some other command
was typed first and then backspaced over). A left-pointing arrow
moves the pointer to the input source for the current unit; since
there can be only one, this is simple.  To move to the output of the
current unit is less defined in the presence of branching.  The
convention used is that a right-pointing arrow moves the pointer to
the first output listed (if any), and a double arrow moves from that
output down to subsequently listed parallel outputs.  Consequently,
left- and right-pointing arrows are not exact inverses, nor is there
an inverse for the double arrow command.  In practice, this should
prove no problem.  On a standard Stanford keyboard these characters
are all grouped together under the right hand, permitting quick,
convenient pointer moving.
	All of the parameters of the unit that is currently being
pointed at (the current unit) will be displayed with the previously
mentioned scratch unit using the same format.  This makes comparison
easy (a frequent desire).  Commands exist to copy either one into the
other; to delete the current unit; and to insert a copy of the
scratch unit into the tree, linking it either before, after, or in
parallel with the current unit.  In addition, when an impulse
response is requested, it is computed along the path from the input
signal up thru the current unit.
		Impulse responses
	Impulse responses are valuable tools for building good
reverberators.  They provide a picture of how the reverberator
will respond when the input signal is a single sample of unit
amplitude -- and thus how it will respond to any signal.  If
a reverberator performs poorly, examining impulse responses at
various points along a path thru the reverberator will usually
indicate where things went wrong.  High quality reverberators
exhibit a smooth, dense, exponential decay.  Since these qualities
are normally discernable after a relatively small number of
samples have been computed, and since the computation itself is
moderately expensive, a time or factor of the default time may be
specified in the impulse command.  As before, the factor will be
remembered.  Also, the display may be remembered in a file.
		Files
	Finally, the tree structure may be written into a file
in a form suitable for execution by the music compiler, or the
whole state of the editor may be saved as a list of commands
which may be read in on some later occasion if further editing
is desired.  In fact, any list of commands at all is acceptable
for file input, with one exception: file input may not be requested
within a file.  Furthermore, if REVED is started in RPG mode (if
you don't know, it's ok), the first thing it will do is try to
read in a file of commands.  The file read from is the same one used
as the default for saving and restoring the state by interactive
command.  Using this capability, clever programs can start REVED
in whatever state they wish.
		Further information
	Information about specific commands will be provided by
REVED upon request.  More detailed information about any aspect
of REVED may be obtained from either the source code or the
author -- whichever you can get your hands on.